Method and system for storing and retrieving tags

ABSTRACT

Storing and retrieving tags can include determining a quantitative weighting factor for each tag, determining a reputation weighting factor for each tag, determining a context weighing factor for each tag, determining an expiry weighting factor for each tag, and determining, using a server, an overall weighting factor for each tag by calculating an average of the weighting factors. The relevance of each tag can be visually reflected in the tag cloud based on the overall weighting factor.

BACKGROUND

In recent years web-based systems such as Enterprise Information Portalshave gained importance in many companies. Latter integrate, as a singlepoint of access, various applications and processes into one homogeneoususer interface. Today, such systems are comprised of a huge amount ofcontent. They are no longer exclusively maintained by an IT departmentinstead, Web 2.0 techniques are used increasingly, allowing usergenerated content to be added. These systems grow quickly and in a moreuncoordinated way as different users possess different knowledge andexpertise and obey to different mental models.

The continuous growth makes access to really relevant informationdifficult. Users need to find task- and role-specific informationquickly. Thus, users often miss out on resources that are potentiallyrelevant to their tasks, simply because they never come across them. Onthe one hand, users obtain too much information that is not relevant totheir current task, on the other hand, it becomes cumbersome to find theright information and they do not obtain all the information that wouldbe relevant.

BRIEF SUMMARY

An aspect can include a method of storing and retrieving tags. Themethod can include determining a quantitative weighting factor for eachtag, determining a reputation weighting factor for each tag, determininga context weighing factor for each tag, determining an expiry weightingfactor for each tag, determining, using a server, an overall weightingfactor for each tag by calculating an average of the weighting factors,and visually reflecting the relevance of each tag in the tag cloud basedon the overall weighting factor.

Another aspect can include a method of storing and retrieving tags. Themethod can include determining a reputation weighting factor for eachtag using a server and visually reflecting the relevance of each tag inthe tag cloud based, at least in part, upon the reputation weightingfactor.

Another aspect can include a method of storing and retrieving tags. Themethod can include determining an expiry weighting factor for each tagusing a server and visually reflecting the relevance of each tag in thetag cloud based, at least in part, upon the expiry weighting factor.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The embodiments of the present invention are illustrated by way ofexample and are not limited by the shape of the figures of the drawingsin which:

FIG. 1A illustrates the main components available in a prior arttagging-enabled system,

FIG. 1B-D illustrates prior art tag widgets invoked by the prior arttagging-enabled system,

FIG. 1E illustrates the interaction process within a prior arttagging-enabled system,

FIG. 2A illustrates an inventive tagging-enabled system,

FIG. 2B shows a preferred embodiment of the storage implementation ofthe present invention,

FIG. 2C illustrates an inventive tag widget for quantitative tagging,

FIG. 2D illustrates an inventive tag widget for reputation tagging,

FIG. 2E illustrates an inventive tag widget for expiry tagging, and

FIG. 2F illustrates an interaction process within the inventivetagging-enabled system.

DETAILED DESCRIPTION

The recent popularity of collaboration techniques on the Internet,particularly tagging and rating, provides new means for bothsemantically describing Portal content as well as for reasoning aboutusers' interests, preferences and contexts.

Tagging is the process of assigning keywords (or metadata) to resources.A tag itself is “some” metadata associated to a resource. Tagsthemselves are non-hierarchical keywords taken from an uncontrolledvocabulary. A resource is an entity uniquely identifiable (addressable).

Tags can add valuable meta-information and even lightweight semantics toweb resources.

Rating is the evaluation or assessment of something, in terms of quality(as with a critic rating a novel), quantity (as with an athlete beingrated by his or her statistics), or some combination of both. I.e. it isthe process of assigning (e.g. numeric) “values” to resources indicatinghow much people “like” those. A rating itself is “some value” associatedto a resource. Ratings themselves are chosen from an interval ofpossible “values” whereas the one end of the interval usually refers to“dislike” and the other to “like”

FIG. 1A depicts the main components available in the prior arttagging-enabled system:

The system is comprised of server side 1 and client side components 2 asin typical web (client/server) architectures.

The client-side 1 is comprised of user-interfacing components (40) whichrun in web clients (usually browsers). These user-interfacing componentsfulfill two tasks: first, allowing users to assign new tags (or ratings)to resources, second allowing users to inspect available tags (orratings) for one or a set of resources (information retrieval).

Tag widgets (400) enable people to tag resources/content. Tag clouds(410) are the visual depiction of all tags available in the system.Latter allow people to navigate through the entire tag space. Rating(420) widgets enable people to rate resources/content.

FIG. 1B shows a typical tag widget. The tag widget is always invoked forexactly one single resource, e.g. a page or a portlet for which eitherthe available tags shall be inspected or to which new tags shall beassigned. The tag widget usually displays some detail data about theresource itself, e.g. title and description and the tags being alreadyavailable. It provides an input field to specify new tags and buttons toapply/submit these new tags.

FIG. 1C shows a typical tag cloud. The tag cloud is usually invoked fora certain scope (set of resources, e.g. all books or all moviesavailable in the system). The tags being displayed is the set of alltags that have been assigned to all resources within the current scope.The font size of a tag represents how often this tag has been appliedwith respect to the current scope. Often users can switch betweendifferent views, e.g. a view displaying all tags, a view displaying thetags recently added, a view displaying the tags most often clicked, aview containing only the tags he applied himself and so forth. A slideroften allows to display more or less tags.

FIG. 1D shows a typical rating widget (embedded in a tag widget). The 5stars presented at the top indicate how good the resource has beenrated—1 highlighted star usually means “poorly” rated, 5 usually“excellent” rated; users can apply their own rating by clicking on oneof the 5 starts displayed.

The server side 2 is structured as follows:

At the bottom level it is shown the system storage (10) which maintainswhich resources (130) and users (140) exist in the system. Users canassign tags (101) stored in the tag storage (100) to these resources;similar ratings (121) can be stored.

The weighting engine (20) is responsible for calculating the weighting(i.e. importance) for each single tag before it is displayed to a user.

The service API (30) allows interacting with the system.

For end-users tag weightings become apparent in tag clouds which displayavailable tags with respect to a certain scope. More often applied tagsare displayed larger than less often applied ones.

FIG. 1E shows the prior art interaction process in a tag-enabled system.For inspecting which tags are available for a certain resource the userfirst invoked the tag widget (1), which calls the service APIs askingfor the available tags (2), which calls the tag weighting engine (3)which retrieves the list of available tags from the data storage (4).The tag weighting engine then calculates the tag weights based on tag“frequency” (5) and returns the result via the service APIs back to thetag widget (6) which displays the tags (7).

Optionally the user can then specify new tags (8) which are then storedvia the service APIs in the data storage (9).

Note that the process is similar for interacting with the tag cloud,except that here tags are retrieved for more than one resource and newtags cannot be applied.

In prior art tag-enabled systems the weighting (i.e. the importance) oftags only depends on the frequency of their occurrence. I.e. a tagapplied more often with respect to a certain scope is regarded of higherimportance than a tag applied less often.

It is object of the present invention to provide an improved mechanismfor adapting tag weightings according to different metrics. This objectis solved by the features of the independent claims. Further preferredembodiments of the present invention are laid down in the dependentclaims.

The embodiments of the present invention provide a method and system forstoring and retrieving tags. Each tag is associated with a resource,upon a user's request. A tagging GUI is displayed which presents theavailable tags for one particular resource and/or a tag cloud GUI isdisplayed which presents tags for more than one resource. The taggingGUI allows to assign new tags to single resources. The tag cloud GUIenables users to search for resources which have been assigned certaintags. In the tag cloud GUI the relevancy of each single tag is visuallyreflected by its weighting factor which is determined by the frequencyof occurrence. The method is characterized by the further steps:

determining a quantitative weighting factor for each single tag byinvoking a quantitative-engine, and/or

determining a reputation weighting factor for each single tag byinvoking a reputation-engine, and/or

determining a context weighing factor for each single tag by invoking ofa context-engine

determining a expiry weighting factor for each single tag by invoking aexpiry-engine, and/or

determining the overall weighting factor for each of said single tag bycalculating the average of all the weighting factors, and

visually reflecting the relevance of each single tag in the tag cloudbased on its determined overall weighting factor.

In a preferred embodiment the quantitative-engine comprises the stepsof:

-   -   a) Receiving a portal page including a tag widget and/or the tag        cloud and a GUI.    -   b) Providing user-based tag weighting adaptation options by        displaying −, + and ! (not) icons for each tag.    -   c) Triggering user-based tag weighting adaptation by letting the        user click on the displayed −, +, or ! icon.    -   d) Increasing or decreasing the tag count depending on the        user's interaction.

In a further preferred embodiment the reputation-engine comprises thesteps of:

a) Receiving a portal page including a tag widget allowing to tag acertain item.

b) Allowing the user to specify tags to be applied to the item to betagged.

c) Before storing the tag calculating the user's reputation to associatea weighting to the tag being applied

-   -   Possible metric: How many tags has the user already applied?    -   Possible metric: What is the average rating of the tags the        users has applied? (Req. the option to rate tags)

d) Storing the tag together with the user reputation-based weighting.

In further preferred embodiment the expiry-engine comprises the stepsof:

a) Receiving a portal page including a tag widget allowing to tag acertain item.

b) Allowing the user to specify tags to be applied to the item to betagged.

c) Allowing to specify validate dates for the tag (start date, end date,etc.) describing in which time frames it should live.

d) Storing the tag together with its “validity range”.

In a further preferred embodiment the context-engine comprises the stepsof:

a) Receiving a portal page including a tag widget allowing to tag acertain item.

b) Allowing the user to specify tags to be applied to the item to betagged.

c) Further allowing to specify the context in which this tag should bevalid or automatically detecting the context in which it is applied

d) Storing the tag together with its context profile.

FIG. 2A illustrates the new weighting engines added to the prior arttagging-enabled system.

Quantitative-Engine 210

In the prior art systems it is assumed that tags can only have “positivecharacter”.

I.e. it is assumed that a resource can be tagged with a term to describethat the resource has something to do with this term, but also assumedthat a resource cannot be tagged with a term to describe that theresource has nothing to do with it. It is latter referred as negativetagging. Negative tagging can be done manually (the user specifies a tagto be negative) or automatically (the system recognizes that a certainterm is the opposite of another). In the first scenario a user couldexplicitly tag some pages with “soccer” and a subset of them with “notGermany” to indicate that some of the tagged soccer pages have nothingto do with German soccer.

In addition to that aspect there are usually no means for single usersto express that a certain tag is of less relevancy for them.

In a preferred embodiment of the present invention the interactionprocess based on the Quantitative Engine 210 comprises the followingsteps:

a) Receiving a portal page including a tag widget and/or the tag cloudand a GUI,

b) Providing user-based tag weighting adaptation options by displaying−, + and ! (not) icons for each tag,

c) Triggering user-based tag weighting adaptation by letting the userclick on the displayed −, +, or ! icon, and

d) Increasing or decreasing the tag count depending on the usersinteraction.

As indicated, in the preferred embodiment a plus- and a minus sign ispresented besides each tag being displayed. In addition, when applying atag, a not-sign is presented.

Clicking the not-sign when applying a tag allows users to express that aresource has nothing to do with the term applied, a helpful feature formore fine-granular categorization of resources.

E.g., users could tag some resources with the term “Web 2.0” and a fewof them with “not” “scientific”. This helps users to quickly find allWeb 2.0 related resources and to quickly distinguish between thescientific and non scientific ones among them.

Reputation-Engine 230

As explained above, in the prior art systems it is assumed that theweighting (i.e. the importance) of tags only depends on the frequency oftheir occurrence.

The embodiments of the present invention additionally allow theweighting of a tag to be dependent on the reputation (or expertise) of auser. I.e. that tags applied by more experienced users have higherweightings, and thus higher influence on what content the community ispresented (or recommended) with, than tags from less experienced users.

The embodiments of the present invention allow to point users to morerelevant content as we assume experts to know better what the communityshould focus on.

The interaction process based on the Reputation Engine 230 comprises thefollowing steps:

a) Receiving a portal page including a tag widget allowing to tag acertain item,

b) Allowing the user to specify tags to be applied to the item to betagged,

c) Before storing the tag calculating the user's reputation to associatea weighting to the tag being applied

-   -   Possible metric: How many tags has the user already applied?    -   Possible metric: What is the average rating of the tags the        users has applied? (Req. the option to rate tags)

d) Storing the tag together with the user reputation-based weighting.

The weight of the tags in the tag cloud only reflects the count of thetag. The magenta colored tags are tags applied from user “UserA” and thecyan colored tags are applied from user “UserB”.

The 2nd tag cloud also considers the reputation level of the user, whichapplied the tag, to calculate the tag weight. Therefore it is allowedusers to apply ratings to tags and to users of the community. Thereputation level of a user could be determined by, e.g. calculating themedian overall ratings applied to the user and overall ratings appliedto tags of the user.

The FIG. 2B shows, that user “UserB” got a better average rating thanuser “UserA”. It can be seen the impact of this reputation levelbeneath. Even though, the tag “TagB” is applied as often as the tag“TagF”, it is displayed with a lesser weight as tag “TagF”, because ofthe better reputation level of “UserB” compared to “UserA”.

E.g., in development team it is assumed that the tagging behavior of theteam or technical lead of higher importance. With reputation-basedtagging we also ensure that “incorrect or less suited” tags perceivelower weightings (influence). E.g., a newbie might apply a more“incorrect/less suited” tag as he just misunderstands.

Two mechanisms to determine the underlying reputation of a user areproposed:

First it is allowed users to be directly rated (e.g. a rating from 1 to5 stars) by other users. Second, it is allowed users to rate tags whichallows to calculate an average rating for all tags a certain user hasapplied; this average rating might be used as the reputation factor.

Expiry-Engine 200

In prior art tagging-enabled systems it is assumed that tags can beapplied once and stay alive until they are manually deleted again. Thisleads to tag-space littering as most users never deleted tags anymoreeven if they became obsolete. The fact that tags do not remain validforever occurs in Portals that provide dynamic content very often. Thisresults in having a lot of tags assigned to resources that do notdescribe the resource adequately nor express the resources relevancy tothe community appropriately anymore.

It is proposed to introduce a tag expiry mechanism allowing users tospecify a chronological validity for tags when assigning them to aresource. Taggers can give tags a start date, an end date or a timeframe in between they live.

We also allow tags that are assigned a “lifetime” to become more (orless) important as time passes by. For latter we allow taggers to selectfrom a list of predefined weighting functions that influence tag weightsbased on time factors or to define their own function.

The interaction process based on the Expiry Engine 200 comprises thefollowing steps:

a) Receiving a portal page including a tag widget allowing to tag acertain item,

b) Allowing the user to specify tags to be applied to the item to betagged,

c) Further allowing to specify validate dates for the tag (start date,end date, etc.) describing in which time frames it should live, and

d) Storing the tag together with its “validity range”.

A clock icon in the upper right corner of a tag in the tag cloud,indicates that a lifetime is applied to the tag. If only one user hasapplied a lifetime to the tag, a tooltip appears during hovering overthe tag and displays the dates of the lifetime. Otherwise, the clockicon implies that multiple lifetimes from different users are applied tothe tag. The tag cloud could be filtered by specifying a date ordragging the date slider to the past or future. It let you navigatealong the time line of the tag cloud and offers a filtered view of thecloud at the current time. To apply a tag with a lifetime, the userselects with a date picker the start date, the end date or both.

The new tags become apparent in tag clouds with respect to theirvalidity again.

E.g. if there is a page in the Portal system providing information aboutthe Olympic Games 2012, this page might become more and more interestingto users as we get nearer to the year 2012 and less interesting after2012. Thus users can specify that the tag should not be available before2011, vanish after 2013 and become more important from 2011 till 2012and less important from 2012 till 2013. Thus, tag expiry is yet anothermechanism to help the community to focus on what is currently reallyrelevant.

Moreover, tag expiry allows us to neglect “invalid” tags from beingconsidered when doing content adaptation or recommendation.

Context-Engine 220

Some tags are often used or applied in certain contexts only.

Of course tags needed by a user depend on the context he is acting in.

I.e. always displaying all tags part of a tag space is often notreasonable.

E.g. when traveling a user might be interested in tags such as airport,traffic information, weather—tags in which he might not be interestedwhen being at the office.

Moreover, the importance of tags can change as users contexts change.

In a fictive development team the management might have decided that themost important hype topic is “tagging & rating”.

Thus people started to extensively tag all resources that have somethingto do with this topic with “hot”.

Weeks later management revised this decision and regarded “tagging &rating” as not very important anymore.

Thus, resources should not be tagged/rated “hot” anymore

Thus it is proposed a mechanism to associate tags to certain contextprofiles.

The interaction process based on the Context Engine 220 comprises thesteps:

a) Receiving a portal page including a tag widget allowing to tag acertain item,

b) Allowing the user to specify tags to be applied to the item to betagged,

c) Further allowing to specify the context in which this tag should bevalid or automatically detecting the context in which it is applied,

d) Storing the tag together with its “context profile”.

The new tag weightings become apparent in tag clouds with respect totheir context profile and the currently active context profile again.

Contextual information can also be used in a different variation:

E.g. two tags “china” and “images” applied could express several things:Images from china; images about china, images drawn by Chinese artistsand so forth.

There could also just be some nice images on the underlying resource andsome side-information about China.

What it really means depends on in which context both tags have beenapplied.

The real meaning can be received statistically from crawling the web andtaken into consideration

Tag bags 110 can be created by users to group tags together (independentfrom any resource categorization); users could e.g. create a bag“sports” containing tags referring to sports stuff only like “soccer” or“basketball”.

Tags can belong to different contexts (150); i.e. some tags are moreimportant than others depending on the context a user is acting in; thecontext storage contains all contexts generally available. Users canswitch between active contexts (or the system could do soautomatically). Contexts identify themselves by a set of attributes andtheir values (like date, location, etc.).

FIG. 2B shows a preferred embodiment of the storage implementation ofthe present invention.

The resources table 20 reflects the entities to which tags (or ratings)can be assigned. A resource has a unique ID making it identifiable, acreation and modification date and localized titles and descriptions. Aresource also has an owner, the user who created or currently owns theresource.

Users 60 are the persons being part of the community interacting withthe system. Users have an ID and, as resources, creation andmodification dates, as well as a human-readable user name and acorresponding password; latter two are used as credentials for logginginto the system, too.

Tags 70 have a unique ID making them identifiable, as well as, such asresources, creation and modification date. Tags are associated toresources, whereas resources could also be tags (or ratings) again (i.e.tags and ratings can become taggable resources, too). Tags have owners,identifying the person who has applied the tag to a resource. Tags alsohave a localized name, of course.

For realizing the tag expiration mechanisms tags can optionally have astart and end date set which reflects their lifetime. If only the startdate is set the tag does only become active after that date, afterwardsliving forever. If only the end date is set the tag expires on thatdate, being active only before. If both is set the tag only livesbetween both dates.

The expiration function ID refers to a function that controls how timeaffects the tag's weight.

Tags can also have set the flags IS_FAVORITE or IS_NEGATIVE whichreflect whether the tag is generally one of the user's favorite tags(independent from the underlying content to which it has been assigned)or whether it is a negative tag (explained in the enclosed text).

Tags can also have a reference to a context they belong to (explainedlater).

Categories 10: One important question is how resources and thus tags canbe categorized (grouped); e.g. If you do not want to retrieve all tagsfor a single resources, but all tags to a group of resources, e.g. allbooks or all movies; this is what categories are used for.

Each resource can be part of none, one or more categories.

A category 10 has an unique ID, creation and modification dates,localized names and descriptions as well as references to tags thatbelong to it.

Similar than with tags, ratings 50 have IDs, creation and modificationdates, an owner, and reference a resource (which can also be a tag, ofcourse). Other than tags they have a numeric rating value.

Tag bags can be created by users to group tags together (independentfrom any resource categorization); users could e.g. create a bag“sports” containing tags referring to sports stuff only like “soccer” or“basketball”.

Tag bags 80 can be easily accessed via UI fragments. Tag bags have aunique ID, creation and modification dates, localized titles anddescriptions and references to tags that belong to the bag.

Contexts 30: Tags can belong to different contexts; i.e. some tags aremore important than others depending on the context a user is acting in.The context table contains all contexts generally available. Users canswitch between active contexts (or the system could do soautomatically). Context 30 identify themselves by a set of attributesand their values (like date, location, etc.). Contexts 30 again have anunique ID, creation and modification dates, localized names anddescriptions and refer to profile data which in turn contains a set ofdescribing attributes and values.

The entire interaction process within the inventive tagging-enabledsystem is illustrated in FIG. 2F.

One change is that the tag weighting engine calculates tag weightings ontags' “frequency” only. It invokes sub-engines to calculate a more finegranular tag weighting.

As said, in prior art systems, the overall weighting for a single tagwas only based on its frequence of occurrence.

As part of this invention the overall weighting for a single tag is, asalready indicated, based on several metrics, making the weighting morereliable and accurate. Its overall weighting influences the visualrepresentation of a tag in the widget (or tag cloud) and thus itsimportance.

The process to trigger the tag widget and to calculate the overall tagweighting is as follows:

During surfing through the information system, e.g. a Portal system, theuser decides to inspect tags being available. As for each taggableresource buttons are available to launch the so called tag widget theuser clicks one of these buttons for the resource he is interested in,e.g. a certain page (1).

As a result the tag widget appears (note that the tag widget might be aclient-side component). As the tag widget is responsible for displayingthe tags that have been assigned to this resource, whereas, as said,each tag is displayed in accordance to its importance (e.g. by usingdifferent font sizes or colouring) it sends a request to the server (or,more precisely, the service API responsible for the taggingfunctionality) asking for the required information (2).

In fact, the service API is responsible for returning both, the simplelist of tags that have been assigned the resource and a weighting foreach tag. Thus, the service API now invokes the tag weighting enginewhich performs two major operations (3):

First, it retrieves the list of tags available for the resource beingrequested by querying the underlying data storage which maintains therelationship between resources and tags (4). Second it invokes severalsub-engines in sequence to determine an overall weighting for each tagof the previously determined list of tags:

The tag weighting engines invokes the quantitative engine (respondingwith a weighting factor F1) (6), the reputation engine (responding witha weighting factor F2) (7), the context engine (8) (responding with aweighting factor F3), and the expiry engine (9) (responding with aweighting factor F4). Based on the factors F1 . . . F4 the tag weightingengines calculates the overall weighting, e.g. based on the average ofthe values F1 . . . F4 5. After that the tag weighting engines returnsthe result (the list of tags and the overall weighting for each tag) tothe service API (10).

The service API in turn returns the result to the tag widget.

The tag widget then displays the tags, whereas each tag is displayed inaccordance to its importance (i.e. its overall weighting) (11).

The user is finally given the option to assign new tags to the resourcevia the tag widget (12). New tags are then stored in the previouslymentioned data storage via the service API, too (13).

As will be appreciated by one skilled in the art, the present inventionmay be embodied as a system, method or computer program product.Accordingly, the present invention may take the form of an entirelyhardware embodiment, an entirely software embodiment (includingfirmware, resident software, micro-code, etc.) or an embodimentcombining software and hardware aspects that may all generally bereferred to herein as a “circuit,” “module” or “system.” Furthermore,the present invention may take the form of a computer program productembodied in any tangible medium of expression having computer usableprogram code embodied in the medium.

Any combination of one or more computer usable or computer readablemedium(s) may be utilized. The computer-usable or computer-readablemedium may be, for example but not limited to, an electronic, magnetic,optical, electromagnetic, infrared, or semiconductor system, apparatus,device, or propagation medium. More specific examples (a non-exhaustivelist) of the computer-readable medium would include the following: anelectrical connection having one or more wires, a portable computerdiskette, a hard disk, a random access memory (RAM), a read-only memory(ROM), an erasable programmable read-only memory (EPROM or Flashmemory), an optical fiber, a portable compact disc read-only memory(CDROM), an optical storage device, a transmission media such as thosesupporting the Internet or an intranet, or a magnetic storage device.Note that the computer-usable or computer-readable medium could even bepaper or another suitable medium upon which the program is printed, asthe program can be electronically captured, via, for instance, opticalscanning of the paper or other medium, then compiled, interpreted, orotherwise processed in a suitable manner, if necessary, and then storedin a computer memory. In the context of this document, a computer-usableor computer-readable medium may be any medium that can contain, store,communicate, propagate, or transport the program for use by or inconnection with the instruction execution system, apparatus, or device.The computer-usable medium may include a propagated data signal with thecomputer-usable program code embodied therewith, either in baseband oras part of a carrier wave. The computer usable program code may betransmitted using any appropriate medium, including but not limited towireless, wireline, optical fiber cable, RF, etc.

The invention claimed is:
 1. A system for storing and retrieving tags,comprising: a server configured to perform operations comprising:determining a quantitative weighting factor for each tag; determining areputation weighting factor for each tag; determining a context weighingfactor for each tag; determining an expiry weighting factor for eachtag; determining an overall weighting factor for each tag by calculatingan average of the weighting factors; and visually reflecting therelevance of each tag in the tag cloud based on the overall weightingfactor, wherein the server is further configured to perform operationscomprising: receiving a portal page including a tag widget allowing totag a certain item; allowing the user to specify tags to be applied tothe item to be tagged; before storing the tag calculating the user'sreputation to associate a weighting to the tag being applied; storingthe tag together with the user reputation-based weighting.
 2. The systemof claim 1, wherein the server is further configured to performoperations comprising: receiving a portal page including a tag widget;providing user-based tag weighting adaptation options by means of icons;triggering user-based tag weighting adaptation options by letting theuser select the displayed icons; and increasing the tag count dependingon the users interaction.
 3. The system of claim 1, wherein the serveris further configured to perform operations comprising: receiving aportal page including a tag cloud and a GUI; providing user-based tagweighting adaptation options by means of icons; triggering user-basedtag weighting adaptation options by letting the user select thedisplayed icons; and increasing the tag count depending on the usersinteraction.
 4. The system of claim 1, wherein the server is furtherconfigured to perform operations comprising: receiving a portal pageincluding a tag widget or the tag cloud and a GUI; providing user-basedtag weighting adaptation options by means of icons; triggeringuser-based tag weighting adaptation options by letting the user selectthe displayed icons; and decreasing the tag count depending on the usersinteraction.
 5. The system of claim 1, wherein the server is furtherconfigured to perform operations comprising: receiving a portal pageincluding a tag widget allowing to tag a certain item; allowing the userto specify tags to be applied to the item to be tagged; allowing theuser to specify validate dates for the tag describing in which timeframes it should live; and storing the tag together with a validityrange for the tag defined by the validate dates.
 6. The system of claim1, wherein the server is further configured to perform operationscomprising: receiving a portal page including a tag widget allowing totag a certain item; allowing the user to specify tags to be applied tothe item to be tagged; allowing the user to specify a context in whichthis tag should be valid; and storing the tag together with its contextprofile.
 7. The system of claim 1, wherein the server is furtherconfigured to perform operations comprising: receiving a portal pageincluding a tag widget allowing to tag a certain item; allowing the userto specify tags to be applied to the item to be tagged; automaticallydetecting a context in which it is applied; and storing the tag togetherwith its context profile.
 8. A computer program product for of storingand retrieving tags, the computer program product comprising: a computerreadable storage medium having stored thereon program code, wherein thecomputer readable storage medium is not a transitory, propagating signalper se, when executed the program code configures a server to performexecutable operations comprising: determining a quantitative weightingfactor for each tag; determining a reputation weighting factor for eachtag; determining a context weighing factor for each tag; determining anexpiry weighting factor for each tag; determining an overall weightingfactor for each tag by calculating an average of the weighting factors;and visually reflecting the relevance of each tag in the tag cloud basedon the overall weighting factor, wherein the server is furtherconfigured to perform operations comprising: receiving a portal pageincluding a tag widget allowing to tag a certain item; allowing the userto specify tags to be applied to the item to be tagged; before storingthe tag calculating the user's reputation to associate a weighting tothe tag being applied; storing the tag together with the userreputation-based weighting.
 9. The computer program product of claim 8,wherein the computer readable storage medium stores program code that,when executed, further configures a server to perform executableoperations comprising: receiving a portal page including a tag widget;providing user-based tag weighting adaptation options by means of icons;triggering user-based tag weighting adaptation options by letting theuser select the displayed icons; and increasing the tag count dependingon the users interaction.
 10. The computer program product of claim 8,wherein the computer readable storage medium stores program code that,when executed, further configures a server to perform executableoperations comprising: receiving a portal page including a tag cloud anda GUI; providing user-based tag weighting adaptation options by means oficons; triggering user-based tag weighting adaptation options by lettingthe user select the displayed icons; and increasing the tag countdepending on the users interaction.
 11. The computer program product ofclaim 8, wherein the computer readable storage medium stores programcode that, when executed, further configures a server to performexecutable operations comprising: receiving a portal page including atag widget or the tag cloud and a GUI; providing user-based tagweighting adaptation options by means of icons; triggering user-basedtag weighting adaptation options by letting the user select thedisplayed icons; and decreasing the tag count depending on the usersinteraction.
 12. The computer program product of claim 8, wherein thecomputer readable storage medium stores program code that, whenexecuted, further configures a server to perform executable operationscomprising: receiving a portal page including a tag widget allowing totag a certain item; allowing the user to specify tags to be applied tothe item to be tagged; allowing the user to specify validate dates forthe tag describing in which time frames it should live; and storing thetag together with a validity range for the tag defined by the validatedates.
 13. The computer program product of claim 8, wherein the computerreadable storage medium stores program code that, when executed, furtherconfigures a server to perform executable operations comprising:receiving a portal page including a tag widget allowing to tag a certainitem; allowing the user to specify tags to be applied to the item to betagged; allowing the user to specify a context in which the tag shouldbe valid or automatically detecting a context in which the tag isapplied; and storing the tag together with its context profile.